MacTech 1 to 12/MacTech-vol-1-12.toast/Reference/the cmsp digests ('94-'97)/csmp digest Vol 4 No 026

Text File | 1996-12-15 | 50.9 KB | 1,527 lines | [TEXT/R*ch]

C.S.M.P. Digest             Tue, 26 Nov 96       Volume 4 : Issue 26

Today's Topics:

        Algorithms for Lighting effects
        Changing a resource size
        Playing .WAV files
        Program crashes when calling LUpdate!
        RegionToBitmap?
        Saving Linked Lists
        Sending Data via TCP
        [Q] Editor for *huge* text files
        copybits problem



The Comp.Sys.Mac.Programmer Digest is moderated by Mark Aiken
([e-mail]).

The digest is a collection of article threads from the internet
newsgroups comp.sys.mac.programmer.help, csmp.tools, csmp.misc and
csmp.games. It is designed for people who read news semi-regularly and
want an archive of the discussions.  If you don't know what a
newsgroup is, you probably don't have access to it. Ask your systems
administrator(s) for details. If you don't have access to news, you
may still be able to post messages to the group by using a mail server
like anon.penet.fi (mail [e-mail] for more information).

Each issue of the digest contains one or more sets of articles (called
threads), with each set corresponding to a 'discussion' of a particular
subject.  The articles are not edited; all articles included in this digest
are in their original posted form (as received by our news server at
ee.mcgill.ca).  Article threads are not added to the digest until the last
article added to the thread is at least two weeks old (this is to ensure that
the thread is dead before adding it to the digest).  Article threads that
consist of only one message are generally not included in the digest.

The digests can be obtained by email, ftp or through the World Wide Web.

If you want to receive the digest by mail, send email to
[e-mail] with no subject and one of the following commands
as body:

    help                        Sends you a summary of commands
    subscribe csmp                      Adds you to the mailing list
    unsubscribe csmp                    Removes you from the list

Once you have subscribed, you will automatically receive each new
issue as it is created.

Back issues are available by ftp from Info-Mac mirror sites in the
per/csmp subdirectory, e.g.

  ftp://sumex-aim.stanford.edu/info-mac/per/csmp/

The contents of all back issues can be searched by accessing the
following URL, courtesy of Andrew Barry ([e-mail]):

    http://marvin.stattech.com.au/search.html

They can also be searched through the following URLs, thanks to
Tim Tuck ([e-mail]):

    http://wais.sensei.com.au/searchform.html
    wais://wais.sensei.com.au:210/csmp?

-------------------------------------------------------

>From Dirk Johnson <[e-mail]>
Subject: Algorithms for Lighting effects
Date: Tue, 12 Nov 1996 17:43:50 -0800
Organization: Apple

I was wondering if anyone could point me to any algorithms or examples
that show how to do lighting effects on colors.  For example, if a
person carrying a candle walks into a dark room, what algorithm would be
used to brighten the colors?

Any help is appreciated.

Dirk Johnson

+++++++++++++++++++++++++++

>From [e-mail]
Date: 14 Nov 1996 01:41:52 GMT
Organization: AOL http://www.aol.com

>>
I am not sure what exactly you want. For lighting a lot of people use a
shade table which is a 2d array with 1 index being the color and the
second being the intensity.
<<

What do you do for 16-bit?  Same thing, but with a larger array, sort of
like an inverse color table map?  Would the right-shifting (to reduce a
16-bit color to the table resolution) and the table lookups really be
faster than the intensity multiplication?

Hmmmm.....

Mike.
+-----------------------------------------------------------+
| Michael A. Kelly                        Eidos Interactive |
| Senior Software Engineer    1825 Trousdale Drive, Suite B |
| [e-mail]                     Burlingame, CA 94010 |
| http://www.eidos.com                  [phone] x115 |
+-----------------------------------------------------------+

+++++++++++++++++++++++++++

>From David Matiskella <[e-mail]>
Date: Wed, 13 Nov 1996 18:30:04 -0800
Organization: University of Washington

On 14 Nov 1996 [e-mail] wrote:

> >>
> I am not sure what exactly you want. For lighting a lot of people use a
> shade table which is a 2d array with 1 index being the color and the
> second being the intensity.
> <<
>
> What do you do for 16-bit?  Same thing, but with a larger array, sort of
> like an inverse color table map?  Would the right-shifting (to reduce a
> 16-bit color to the table resolution) and the table lookups really be
> faster than the intensity multiplication?
>
> Hmmmm.....
>
> Mike.
> +-----------------------------------------------------------+
> | Michael A. Kelly                        Eidos Interactive |
> | Senior Software Engineer    1825 Trousdale Drive, Suite B |
> | [e-mail]                     Burlingame, CA 94010 |
> | http://www.eidos.com                  [phone] x115 |
> +-----------------------------------------------------------+
>
Depends what you are doing. If you image has less than 256 colors you can
give each image its own 16 bit color table. Color tables are sort of cool
since you can easily add things like blinking lights, lights unaffected by
shading, and so on.
    You can also do tablelook ups. With 16 bit 16 bit would be huge
you could do the look up on each 5 bit component. Its rather expensive
costing 3 instructions to extract the color, 3 loads to shade the pixel, 2
instructions to reassemble the pixel and 1 to write it out.  On a 604
multiplication is probaly as fast as table look ups

David Matiskella
[e-mail]



---------------------------

>From Benoit Grange <[e-mail]>
Subject: Changing a resource size
Date: 13 Nov 1996 19:09:56 +0100
Organization: Guest of OLEANE - PIPEX International


I have a problem changing a resource Size, ie:

    Handle h = GetResource('blob', 128); // We should check
    long   size = GetHandleSize(h); // We should check

    size += 64;

    SetHandleSize(h, size);

    if (ResError())
        Debugger();

I always get a -111 error (operating on a free block).

Is this the correct way to do it ?

--
Benoit Grange - OLEANE Network Operations Center

Support technique et operationnel Oleane :  [e-mail]
Informations commerciales sur Oleane     :  [e-mail]

Computers run on smoke, when the smoke goes out, computers stop working...

+++++++++++++++++++++++++++

>From [e-mail] (Norman Franke)
Date: Wed, 13 Nov 1996 13:37:31 -0800
Organization: Lawrence Livermore National Laboratory

In article <[e-mail]>, Benoit Grange
<[e-mail]> wrote:

>         SetHandleSize(h, size);
>
> I always get a -111 error (operating on a free block).

Use SetResourceSize instead.

--
Norman Franke
[e-mail]

---------------------------

>From [e-mail] (Andrew Wright)
Subject: Playing .WAV files
Date: Tue, 12 Nov 1996 15:47:29 +1000
Organization: Prentice Centre, University of Queensland

Hi all. I was wondering could anyone point me towards some info on playing
.wav files on the Mac? (Obviously, I mean adding this functionality to my
app, not just playing them! :) Even better, is there a share/free ware
library out there? Thanks very much.

--
Regards,               |         Visit me on-line
Andrew Wright          |                at
[e-mail] | http://student.uq.edu.au/~s341797

+++++++++++++++++++++++++++

>From [e-mail] (Jim Reekes)
Date: Wed, 13 Nov 1996 17:35:43 -0800
Organization: Apple Computer, Inc.

In article <[e-mail]>,
[e-mail] (Andrew Wright) wrote:

> Hi all. I was wondering could anyone point me towards some info on playing
> .wav files on the Mac? (Obviously, I mean adding this functionality to my
> app, not just playing them! :) Even better, is there a share/free ware
> library out there? Thanks very much.

Using the latest QuickTime 2.5, you just open the .wav file using
MoviePlayer and will will play the file just as any other movie file. The
conversion is automatically done in real time. You can also export the
file to another Mac format while within MoviePlayer.

Jim

--
Jim Reekes, Polterzeitgeist |       QuickTime Products R&D
                            |        Sound Manager Expert
Apple Computer, Inc.        | "All opinions expressed are mine, and
2 Infinite Loop  MS 302-3KS |  do not necessarily represent those
Cupertino, CA 95014         |  of my employer, Apple Computer Inc."

---------------------------

>From [e-mail] (Anders Wahlin)
Subject: Program crashes when calling LUpdate!
Date: Thu, 07 Nov 1996 10:04:37 +0100
Organization: HDS

Hello.

I have a dialog with a list in it. In my dialog filter function I call
LUpdate on every update event, like this:

[snip]

 if (theEvent->what == updateEvt) {
      SetPort(theDialog);
      DrawOutlinedButton(theDialog, 1);
      if (resultList != nil) {
         LUpdate((*resultList)->port->visRgn, resultList); /* CRASH */
      }
      FrameRect (&resultListRect);
   }

[snip]

When the dialog is called the first time everything works fine. The
problem comes when I show another dialog above the list dialog and then
then return to it. Then the program crashes.

Any clues?

Thanks you

+++++++++++++++++++++++++++

>From [e-mail] (Roger Bilewicz)
Date: 8 Nov 96 16:56:15 GMT
Organization: Freie Universitaet Berlin

[e-mail] (Anders Wahlin) writes:

>Hello.

>I have a dialog with a list in it. In my dialog filter function I call
>LUpdate on every update event, like this:

>[snip]
>
> if (theEvent->what == updateEvt) {
>      SetPort(theDialog);
>      DrawOutlinedButton(theDialog, 1);
>      if (resultList != nil) {
>         LUpdate((*resultList)->port->visRgn, resultList); /* CRASH */
>      }
>      FrameRect (&resultListRect);
>   }

>[snip]

>When the dialog is called the first time everything works fine. The
>problem comes when I show another dialog above the list dialog and then
>then return to it. Then the program crashes.

>Any clues?

Hi Anders,
you should check if DialogPtr(theEvent.message) = myDialog when you get
an update event. When your code crashes, the update is most probably
targeted to a different window. Nevertheless, you should update that
window rather than to ignore the event!

Hope it helps,
Roger


+++++++++++++++++++++++++++

>From [e-mail]
Date: 13 Nov 1996 23:25:05 GMT
Organization: AOL http://www.aol.com

>>I have a dialog with a list in it. In my dialog filter function I call
LUpdate on every update event, like this:

[snip]

 if (theEvent->what == updateEvt) {
      SetPort(theDialog);
      DrawOutlinedButton(theDialog, 1);
      if (resultList != nil) {
         LUpdate((*resultList)->port->visRgn, resultList); /* CRASH */
      }
      FrameRect (&resultListRect);
   }

[snip]

When the dialog is called the first time everything works fine. The
problem comes when I show another dialog above the list dialog and then
then return to it. Then the program crashes.

Any clues?<<

The best way to handle updating the List in your dialog would be to write
your own dialog hook.

SInt16 YourSmallDLOG(DialogRef theDialog, EventRecord *theEvent, SInt16
item)
{
    // Handle your items here and the return false on everything else
so the dialog mgr
      // will update the rest. I'd look in Inside Macintosh Essential
Tools for more info.
      return false;
}

BBoppie





---------------------------

>From "Aidan Cully" <[e-mail]>
Subject: RegionToBitmap?
Date: 29 Oct 96 13:43:17 -0400
Organization: INTAC Access Corporation - An Internet Service Provider

Hello, I'm writing a program which makes use of Offscreen Graphics Worlds
for drawing into multiple windows, but the problem would most likely also
exist in scenarios where there is more than one window on the screen.

The problem is that CopyBits seems to expect a window that it's drawing
into to be uncovered by any other window.  Fine, so we use CopyMask to clip
to the window's shape.  But CopyMask expects a BitMap, while the Window's
visRgn is a Region.  Is there any RegionToBitmap sort of function I could
use to generate the proper mask for CopyMask?

The solution I have come up with requires the creation of a new GWorld
(with bit-depth of 1), setting the clipRgn for that world to be the
window's visRgn and filling the portRect, but this is a very clumsy hack.
Anyone know a better way?

Thanks in advance
--aidan
--
You can't find your waitress
    With a geiger counter
She hates you and your friends and you just
    Can't get served without her
        --Tom Waits



+++++++++++++++++++++++++++

>From "Aidan Cully" <[e-mail]>
Date: 29 Oct 96 16:14:25 -0400
Organization: INTAC Access Corporation - An Internet Service Provider

>Hello, I'm writing a program which makes use of Offscreen Graphics Worlds
>for drawing into multiple windows, but the problem would most likely also
>exist in scenarios where there is more than one window on the screen.
>
>The problem is that CopyBits seems to expect a window that it's drawing
>into to be uncovered by any other window.  Fine, so we use CopyMask to
clip
>to the window's shape.  But CopyMask expects a BitMap, while the Window's
>visRgn is a Region.  Is there any RegionToBitmap sort of function I could
>use to generate the proper mask for CopyMask?

Answered my own question.. or rather solved the problem that led to my
question. The problem was that I was drawing to the graphics port that
existed when the application was started, instead of the window's own
graphics port.  Still, BeginUpdate( window ) should force the current
graphics port to be "window".  And there really should be a
RegionToBitmap() function.

Thanks anyway to anyone who had the chance to respond.
--aidan



+++++++++++++++++++++++++++

>From [e-mail] (msoori)
Date: Wed, 30 Oct 1996 16:14:34 GMT
Organization: Bio-Rad Laboratories

CopyBits() uses the srcBits and destBits, which can either be bitmaps or
pixMaps as well as a region that is used as a mask to clip to the shape of
the given region.  What CopyMask does is to use a bit map as a mask
instead of a region.  BitMapToRegion() does convert a bitmap to a region,
but I dont think there is anything to go the otherway (also there is a bug
in the PowerMac with this function - gives you a bigger region than the
actual).

Either way, the window should still be uncovered, or else you wil be
drawing over the other windows as well.  If you are trying to avoid this,
I guess, what you could do is to use CopyBits() with the visRgn of that
window as the mask region.

Good Luck.

In article <AE9BBA7A-8E3DC@199.173.0.243>, "Aidan Cully"
<[e-mail]> wrote:

> Hello, I'm writing a program which makes use of Offscreen Graphics Worlds
> for drawing into multiple windows, but the problem would most likely also
> exist in scenarios where there is more than one window on the screen.
>
> The problem is that CopyBits seems to expect a window that it's drawing
> into to be uncovered by any other window.  Fine, so we use CopyMask to clip
> to the window's shape.  But CopyMask expects a BitMap, while the Window's
> visRgn is a Region.  Is there any RegionToBitmap sort of function I could
> use to generate the proper mask for CopyMask?
>
> The solution I have come up with requires the creation of a new GWorld
> (with bit-depth of 1), setting the clipRgn for that world to be the
> window's visRgn and filling the portRect, but this is a very clumsy hack.
> Anyone know a better way?
>
> Thanks in advance
> --aidan
> --
> You can't find your waitress
>     With a geiger counter
> She hates you and your friends and you just
>     Can't get served without her
>         --Tom Waits

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

+++++++++++++++++++++++++++

>From Carl R. Osterwald <[e-mail]>
Date: 30 Oct 1996 15:50:17 GMT
Organization: National Renewable Energy Laboratory

In article <AE9BDDE9-4FC92@199.173.0.243> Aidan Cully,
[e-mail] writes:

>>But CopyMask expects a BitMap, while the Window's
>>visRgn is a Region.  Is there any RegionToBitmap sort of function I could
>>use to generate the proper mask for CopyMask?

That's easy--just use PaintRegion().  Set the current port to your
offscreen GWorld and call PaintRegion().

>Answered my own question.. or rather solved the problem that led to my
>question. The problem was that I was drawing to the graphics port that
>existed when the application was started, instead of the window's own
>graphics port.  Still, BeginUpdate( window ) should force the current
>graphics port to be "window".

Applications have the responsibility of maintaining and knowing which
port they are drawing into.  Quickdraw has been this way since about
1982.

>And there really should be a
>RegionToBitmap() function.

There is, see above.

+++++++++++++++++++++++++++

>From [e-mail] (Matthew T. Russotto)
Date: 2 Nov 1996 12:54:12 -0500
Organization: Ghotinet

In article <[e-mail]>,
msoori <[e-mail]> wrote:
}CopyBits() uses the srcBits and destBits, which can either be bitmaps or
}pixMaps as well as a region that is used as a mask to clip to the shape of
}the given region.  What CopyMask does is to use a bit map as a mask
}instead of a region.  BitMapToRegion() does convert a bitmap to a region,
}but I dont think there is anything to go the otherway (also there is a bug
}in the PowerMac with this function - gives you a bigger region than the
}actual).

RegionToBitmap is a.k.a PaintRgn.  Well, not quite-- you create an
old-style GrafPort and a Bitmap the size of the bounding box of the
region, and then PaintRgn into it.  The Grafport can then be trashed.

--
Matthew T. Russotto                                [e-mail]
"Extremism in defense of liberty is no vice, and moderation in pursuit
of justice is no virtue."

+++++++++++++++++++++++++++

>From [e-mail] (Dave Johnson)
Date: Sat, 02 Nov 1996 13:03:49 -0800
Organization: Apple Computer, Inc.

In article <55g1s4$[e-mail]>, [e-mail]
(Matthew T. Russotto) wrote:

> RegionToBitmap is a.k.a PaintRgn.  Well, not quite-- you create an
> old-style GrafPort and a Bitmap the size of the bounding box of the
> region, and then PaintRgn into it.  The Grafport can then be trashed.
>
> --
> Matthew T. Russotto                                [e-mail]
> "Extremism in defense of liberty is no vice, and moderation in pursuit
> of justice is no virtue."

 Why not just use the region directly?: use plain old CopyBits with a
maskRgn instead of copyMask. Apparently it's often even faster than
CopyMask...

Dave Johnson
[e-mail]

+++++++++++++++++++++++++++

>From [e-mail] (Matt Deatherage)
Date: Mon, 04 Nov 1996 00:56:21 -0600
Organization: GCSF, Incorporated

In article <AE9BBA7A-8E3DC@199.173.0.243>, "Aidan Cully"
<[e-mail]> wrote:

> The problem is that CopyBits seems to expect a window that it's drawing
> into to be uncovered by any other window.  Fine, so we use CopyMask to clip
> to the window's shape.  But CopyMask expects a BitMap, while the Window's
> visRgn is a Region.  Is there any RegionToBitmap sort of function I could
> use to generate the proper mask for CopyMask?

I'm missing something basic here, I think.

When you call CopyBits to a window's grafPort, the Window Manager should
already have set the visRgn to only the visible portion of the window.
Since drawing is restricted to the intersection of the clipRgn and visRgn,
CopyBits to a window should never draw outside a window's content area
unless you've messed with the visRgn (a bad idea for windows, but fine for
your own off-screen grafPorts or GWorlds).

That said, getting a bitmap from a region is simple -- make an offscreen
grafPort with a bitmap attached and call PaintRgn or FillRgn, and you're
done.  You shouldn't need to do this for the problem you mention as I read
it, though.

- --------------------------------------------------------------------------
Matt Deatherage                                      <mailto:[e-mail]>
GCSF, Incorporated                                     <http://www.gcsf.com>

+++++++++++++++++++++++++++

>From [e-mail] (Michel Pollet)
Date: Wed, 6 Nov 1996 20:17:12 +0100
Organization: SAT/SAGEM

Dave Johnson <[e-mail]> wrote:

>  Why not just use the region directly?: use plain old CopyBits with a
> maskRgn instead of copyMask. Apparently it's often even faster than
> CopyMask...

Remember to sect it to the visible region of the window itself, because
if you don't, you'll have little bits of control strips and other
floatings drawn uppon..

--
Michel Pollet                       Macintosh developer & MkLinux hacker
Email: [e-mail]                        Phone: [phone]
http://www.inforoute.cgs.fr/pollet/      <-- Have a look at my guitars !

+++++++++++++++++++++++++++

>From [e-mail] (Dave Johnson)
Date: Wed, 06 Nov 1996 11:45:15 -0800
Organization: Apple Computer, Inc.

In article <[e-mail]>, [e-mail]
(Matt Deatherage) wrote:

> In article <AE9BBA7A-8E3DC@199.173.0.243>, "Aidan Cully"
> <[e-mail]> wrote:
>
> > The problem is that CopyBits seems to expect a window that it's drawing
> > into to be uncovered by any other window.  Fine, so we use CopyMask to clip
> > to the window's shape.  But CopyMask expects a BitMap, while the Window's
> > visRgn is a Region.  Is there any RegionToBitmap sort of function I could
> > use to generate the proper mask for CopyMask?
>
> I'm missing something basic here, I think.
>
<SNIP>
> ----------------------------------------------------------------------------
> Matt Deatherage                                      <mailto:[e-mail]>
> GCSF, Incorporated                                     <http://www.gcsf.com>

Aha! Yes, Matt is absolutely right, I missed the original post and only
saw the last bit, about wanting to use copyMask but having a region.

Sounds to me like the problem is simply that you never called SetPort to
set the surrent grafport to the window in question. Simply doing that
automatically clips copybits (and any other QuickDraw drawing) to the
visible contents of the window.

Dave Johnson

+++++++++++++++++++++++++++

>From "Jim Cushing" <[e-mail]>
Date: Wed, 13 Nov 1996 15:32:01 -0500
Organization: University of Florida

I sent a message to the original author, but not to the newsgroup concerning
this problem, and it turned out that my response solved the author's
problem.  So I guess I ought to share it with the rest of the world.

The problem was, CopyBits() only clips to the visible region of the active
port.  If you wish to copy to a window that is not the front window, you
must first SetPort() to the window you wish to CopyBits() to.  Note that
SetPort() does not activate, select, or bring to front any window, it just
makes it the active grafPort.

---------------------------

>From [e-mail] (Andrew McClain)
Subject: Saving Linked Lists
Date: Fri, 08 Nov 1996 11:32:03 -0500
Organization: Illinois Internet Communications, Inc.

How do I save a variable length double linked list to a resource file?

Here is my record structure:

typedef struct LinkRec
{
   OSType         fileType;
   OSType         creator;
   FSSpec         destination;
   Boolean        defaultRec;
   struct LinkRec *prefRec, *nextRec;  /* Double Linked List */
} LinkRec, *LinkRecPtr;

Thank you for any replies.

Sincerely,
Andrew McClain

+++++++++++++++++++++++++++

>From [e-mail] (David Phillip Oster)
Date: 8 Nov 1996 21:51:49 GMT
Organization: Digital Arts & Sciences Corp.

In article <amcclain-0811961132030001@206.62.101.72>, [e-mail]
(Andrew McClain) wrote:

>How do I save a variable length double linked list to a resource file?

>Here is my record structure:

>typedef struct LinkRec
>{
>   OSType         fileType;
>   OSType         creator;
>   FSSpec         destination;
>   Boolean        defaultRec;
>   struct LinkRec *prefRec, *nextRec;  /* Double Linked List */
>} LinkRec, *LinkRecPtr;

The resource map of a resource file has a limit of roughly 2000 entities.
Since this is rather small, you'd do best to do something like the following

write:

   h = NewHandle(0);
   for(p = fistLink; nil != p ; p = p->nextRec){
      if(noErr != (errCode = PtrToHand(p, h, sizeof(LinkRec)))){
         DisposeHandle(h);
         return errCode;
      }
   }
   AddResource(h, 'Link', 128, "\p");
   if(noErr != (errCode = ResError())){
      DisposeHandle(h); // if it was good, resource manager now owns handle
   }
   return errCode;

read:
   h = GetResource('Link', 128);
   HLock(h);
   size = GetHandleSize(h);
   p = (LinkRecPtr) *h;

   for( ; size > 0; size -= sizeof(LinkRec), p++){
      ... left as an exercise: make a copy of p, link it in.
   }
   HUnlock(h);
   HPurge(h);

--
-- Warning: no attempt has been made to verify that the sender is actually David Oster
Give a man a fish: feed him for a day. Teach a man to fish: feed him for life.
Teach a hundred men to fish: deplete the fish stock, destroy an ecosystem.

+++++++++++++++++++++++++++

>From [e-mail] (Jeff Abrahamson)
Date: Sun, 10 Nov 1996 11:00:47 -0600
Organization: PDI

In article <amcclain-0811961132030001@206.62.101.72>, [e-mail]
(Andrew McClain) wrote:

> How do I save a variable length double linked list to a resource file?
>
> Here is my record structure:
>
> typedef struct LinkRec
> {
>    OSType         fileType;
>    OSType         creator;
>    FSSpec         destination;
>    Boolean        defaultRec;
>    struct LinkRec *prefRec, *nextRec;  /* Double Linked List */
> } LinkRec, *LinkRecPtr;
>
> Thank you for any replies.

Presumably you'll read the linked list back into RAM before using it
again. In that case, you can skip the pointers and stream it out:

write:

   // instatiate a stream
   item = first_item_in_list();
   do {
      stream.write(item->fileType);
      stream.write(item->creator);
      stream.write(item->destination);
      stream.write(item->defaultRec);
   } while(item = next_item_in_list());
   // flush stream here

When you read it back in, you just recreate your pointers as you go:

   while(get_next_item_from_stream) {
      link_item_into_list_at_end
   }

// and define get_next_item_from_stream:
   Item *item = new Item;
   item->fileType = stream.read;
   item->creator = stream.read;
   // etc.
   return(item);  // unless EOS, in which case delete item and return nil


Note that the stream here could just be a handle that you've made big
enough for the task. The point is that you use a linked list in RAM for
certain properties of traversal and efficiency that you don't need the
structure in the resource fork to have.

+++++++++++++++++++++++++++

>From David Gillies <[e-mail]>
Date: Mon, 11 Nov 1996 20:38:32 +0000
Organization: University of Bradford

Andrew McClain wrote:
>
> How do I save a variable length double linked list to a resource file?
>
> Here is my record structure:
>
> typedef struct LinkRec
> {
>    OSType         fileType;
>    OSType         creator;
>    FSSpec         destination;
>    Boolean        defaultRec;
>    struct LinkRec *prefRec, *nextRec;  /* Double Linked List */
> } LinkRec, *LinkRecPtr;
>
> Thank you for any replies.
>
If you have a limited number of entries in your list you could save
your list entries out as a series of resources. You might want to
make a meta-structure where the last entry is the resource IDs of the
list entries instead of their addresses. A linked list is a lot easier
to write to a file since it is a linear structure. N-ary trees are
nasty (look at the stuff in IM IV on low-level volume info if you don't
believe me).

The above comes with the caveat that the Resource Manager is not a
database. Read technote wossname in OS on (not) abusing your manager.


--
______________________________________________________________________
David A. G. Gillies                        ([e-mail])
      University of Bradford, Bradford, West Yorkshire, England
_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/

+++++++++++++++++++++++++++

>From [e-mail] (Bryant Brandon)
Date: Tue, 12 Nov 1996 20:45:56 -0600
Organization: Anti Christian Coalition

In article <[e-mail]>, David Gillies
<[e-mail]> wrote:

>Andrew McClain wrote:
>>
>> How do I save a variable length double linked list to a resource file?
>>
>> Here is my record structure:
>>
>> typedef struct LinkRec
>> {
>>    OSType         fileType;
>>    OSType         creator;
>>    FSSpec         destination;
>>    Boolean        defaultRec;
>>    struct LinkRec *prefRec, *nextRec;  /* Double Linked List */
>> } LinkRec, *LinkRecPtr;
>>
>> Thank you for any replies.
>>
>If you have a limited number of entries in your list you could save
>your list entries out as a series of resources. You might want to
>make a meta-structure where the last entry is the resource IDs of the
>list entries instead of their addresses. A linked list is a lot easier
>to write to a file since it is a linear structure. N-ary trees are
>nasty (look at the stuff in IM IV on low-level volume info if you don't
>believe me).
>
>The above comes with the caveat that the Resource Manager is not a
>database. Read technote wossname in OS on (not) abusing your manager.
>
>
>--
>______________________________________________________________________
>David A. G. Gillies                        ([e-mail])
>      University of Bradford, Bradford, West Yorkshire, England
>_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/

   Once I toyed with the idea of using a Handle to a resizeable block in
memory.  The block is filled with little objects representing individual
little links.  The pointers contained within the link objects are offsets
from the beginning of the block(the haddle could be in a static variable
called thisHandle).  With that setup, you could write the entire block
into one resource and read it out again very easily.  You could use a
container class to handle the block.
   Just food for thought...

I'm usually only here on weekends.  If you really want me to see a reply, please mail it.

+++++++++++++++++++++++++++

>From [e-mail] (Tim Fischer)
Date: Wed, 13 Nov 1996 08:48:13 -0600
Organization: Coda Music Technology

In article <[e-mail]>,
[e-mail] (Carl Gustafson) wrote:

> In article <amcclain-0811961132030001@206.62.101.72>, [e-mail]
> (Andrew McClain) wrote:
>
> > How do I save a variable length double linked list to a resource file?
> >
> > Here is my record structure:
> >
> > typedef struct LinkRec
> > {
> >    OSType         fileType;
> >    OSType         creator;
> >    FSSpec         destination;
> >    Boolean        defaultRec;
> >    struct LinkRec *prefRec, *nextRec;  /* Double Linked List */
> > } LinkRec, *LinkRecPtr;
>
> The simple answer is to start at the head, and use AddResource to put each
> link in the file's resource fork. As you go along, just replace the link
> pointers with the resource ID number (cast this number to a long, so that
> it exactly fits in the place of the link pointers.)
>
> The details (like duplicating links first, etc.) are left as an exercise :)
>
> I won't comment on the pros and cons of doing this.

Am I missing something here?

You don't need to store the link information when saving a linked list.
Just traverse the list, and save the data portion in any format you want
to a (resource or data) file in the correct order.  When reloading the
linked list, read in each node and add it to the tail of the list (which
is trivial and efficient assuming your head node points to the tail
(circular doubly-linked list).  If it's not circular, you can just keep
track of the tail on your own-- it's the last node you've added.

Your add routine will take care of recreating the links as you rebuild the
list, just as it did the first time you created the list.

-Tim

--
- -------------------------------------
Tim Fischer

The following email address is mangled to prevent automated
unsolicited junk mail.  Replace the '_AT_' with an '@':

tfischer_AT_codamusic.com

+++++++++++++++++++++++++++

>From [e-mail] (Carl Gustafson)
Date: Wed, 13 Nov 1996 08:50:29 -0500
Organization: Imaging and Computer Vision Center, Drexel University

In article <amcclain-0811961132030001@206.62.101.72>, [e-mail]
(Andrew McClain) wrote:

> How do I save a variable length double linked list to a resource file?
>
> Here is my record structure:
>
> typedef struct LinkRec
> {
>    OSType         fileType;
>    OSType         creator;
>    FSSpec         destination;
>    Boolean        defaultRec;
>    struct LinkRec *prefRec, *nextRec;  /* Double Linked List */
> } LinkRec, *LinkRecPtr;

The simple answer is to start at the head, and use AddResource to put each
link in the file's resource fork. As you go along, just replace the link
pointers with the resource ID number (cast this number to a long, so that
it exactly fits in the place of the link pointers.)

The details (like duplicating links first, etc.) are left as an exercise :)

I won't comment on the pros and cons of doing this.

Carl

--
Carl Gustafson
carl.gustafson at ece.drexel.edu
(busily trying to avoid spammers)
Imaging and Computer Vision Center
Drexel University, Philadelphia, Penna
- ----------------------------------------------------------
I don't speak for Drexel, and Drexel doesn't listen to me...

---------------------------

>From [e-mail]
Subject: Sending Data via TCP
Date: Wed, 6 Nov 1996 20:27:48 GMT
Organization: NETCOM On-line Communication Services (408 261-4700 guest)

I have a question regarding sending data via TCP.

Im trying to write some code which lets users chat with eachother
everything works so far, except for the speed at which it works.

I connect to a server, receive data no problem and then when I want
to send 1 char at a time data "key strokes" it takes a long time
to get the confirmation back.  Should I be using some kind of send
completition routine? or should I be using some kind of queing system
like telnet?

I send the data (pbcontrolasync) and then monitor the .ioresult field
for any errors when it returns without an error I continue.  If I
tried sending additional data before the .ioresult came back noerr it
would crash.

what is the easiest way to send data via tcp "async"?  The way im
doing it doesnt seem to be async.

thanks,

-Edan

+++++++++++++++++++++++++++

>From [e-mail] (Jan C. Zawadzki)
Date: 8 Nov 1996 01:27:17 GMT
Organization: Internet Express (800-592-1240 customer service)

In article <[e-mail]>, [e-mail] says...
>
>I connect to a server, receive data no problem and then when I want
>to send 1 char at a time data "key strokes" it takes a long time
>to get the confirmation back.  Should I be using some kind of send
>completition routine? or should I be using some kind of queing system
>like telnet?

What you are seeing is the optimizations in the TCP/IP device driver.  IP
packets are large (1000+ bytes), and so sending a byte at a time makes little
sense.  The driver maintains a data buffer that you get to fill in, but the
decision to send is based on % full and time since first byte arrived.  You
have no control over this.  I would recommend redesigning your application to
try to cache data.  The other problem is that you are not using the sockets in
non-blocking mode.  In "true" asynch mode there is a callback routine that gets
triggered when data is available on the pipe.  In that routine you can decide
what to do with the data, and your application will appear less "chunky" in
execution (ie. you can continually send data, and continually receive data).

Jan


+++++++++++++++++++++++++++

>From "John Dalgliesh" <[e-mail]>
Date: 10 Nov 96 20:42:11 +1100
Organization: University of New South Wales


--Cyberdog-AltBoundary-00094CE6
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

>I have a question regarding sending data via TCP.
>
>Im trying to write some code which lets users chat with eachother
>everything works so far, except for the speed at which it works.
>
>I connect to a server, receive data no problem and then when I want
>to send 1 char at a time data "key strokes" it takes a long time
>to get the confirmation back.  Should I be using some kind of send
>completition routine? or should I be using some kind of queing system

>like telnet?
>
>I send the data (pbcontrolasync) and then monitor the .ioresult field

>for any errors when it returns without an error I continue.  If I
>tried sending additional data before the .ioresult came back noerr it

>would crash.
>
>what is the easiest way to send data via tcp "async"?  The way im
>doing it doesnt seem to be async.

The problem is that MacTCP buffers send requsts, until it's either got
a certain amount or a certain time has elapsed.
What you could do is continue regardless of whether there's an error -
it's no use making an async request if you're going to wait until it's
complete before proceeding!
Personally, I just do a sync PBControl nad it seems to work at a
perfectly acceptable speed.
Hope this helps!

{P^/


--Cyberdog-AltBoundary-00094CE6
Content-Type: multipart/mixed; boundary="Cyberdog-MixedBoundary-00094CE7"
Content-Transfer-Encoding: 7bit


--Cyberdog-MixedBoundary-00094CE7
Content-Type: text/enriched; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<SMALLER><X-FONTSIZE><PARAM>10</PARAM><FONTFAMILY><PARAM>Geneva</PARAM>=
>I have a question regarding sending data via TCP.

>

>Im trying to write some code which lets users chat with eachother

>everything works so far, except for the speed at which it works.

>

>I connect to a server, receive data no problem and then when I want

>to send 1 char at a time data "key strokes" it takes a long time

>to get the confirmation back.  Should I be using some kind of send

>completition routine? or should I be using some kind of queing system


>like telnet?

>

>I send the data (pbcontrolasync) and then monitor the .ioresult field


>for any errors when it returns without an error I continue.  If I

>tried sending additional data before the .ioresult came back noerr it


>would crash.

>

>what is the easiest way to send data via tcp "async"?  The way im

>doing it doesnt seem to be async.</FONTFAMILY></X-FONTSIZE></SMALLER><=
SMALLER><X-FONTSIZE><PARAM>10</PARAM><FONTFAMILY><PARAM>Geneva</PARAM>


The problem is that MacTCP buffers send requsts, until it's either got
a certain amount or a certain time has elapsed.

What you could do is continue regardless of whether there's an error -
it's no use making an async request if you're going to wait until it's
complete before proceeding!

Personally, I just do a sync PBControl nad it seems to work at a
perfectly acceptable speed.

Hope this helps!


{P^/</FONTFAMILY></X-FONTSIZE></SMALLER>
--Cyberdog-MixedBoundary-00094CE7--

--Cyberdog-AltBoundary-00094CE6--


+++++++++++++++++++++++++++

>From [e-mail] (John Nagle)
Date: Mon, 11 Nov 1996 18:58:32 GMT
Organization: NETCOM On-line Communication Services (408 261-4700 guest)

"John Dalgliesh" <[e-mail]> writes:
>--Cyberdog-AltBoundary-00094CE6
>Content-Type: text/plain; charset=ISO-8859-1
>Content-Transfer-Encoding: quoted-printable
>>I have a question regarding sending data via TCP.
>>Im trying to write some code which lets users chat with eachother
>>everything works so far, except for the speed at which it works.
>>
>>I connect to a server, receive data no problem and then when I want
>>to send 1 char at a time data "key strokes" it takes a long time
>>to get the confirmation back.  Should I be using some kind of send
>>completition routine? or should I be using some kind of queing system
>>I send the data (pbcontrolasync) and then monitor the .ioresult field
>>for any errors when it returns without an error I continue.  If I
>>tried sending additional data before the .ioresult came back noerr it
>>would crash.
>>
>>what is the easiest way to send data via tcp "async"?  The way im
>>doing it doesnt seem to be async.

>The problem is that MacTCP buffers send requsts, until it's either got
>a certain amount or a certain time has elapsed.

    It's not supposed to do that.  TCP delays ACKs, but not sends
when the link is idle.  I know; I invented the standard algorithm
that controls this.  Are synchronous TCP sends waiting for the
ACK to come back, or what?  Most TCP implementations return as soon
as the data has been queued for sending, unless the window is full
because you've been sending large amounts of data.

                    John Nagle

+++++++++++++++++++++++++++

>From [e-mail]
Date: Wed, 13 Nov 1996 07:53:17 GMT
Organization: NETCOM On-line Communication Services (408 261-4700 guest)

>>I have a question regarding sending data via TCP.
>>Im trying to write some code which lets users chat with eachother
>>everything works so far, except for the speed at which it works.
>>
>>I connect to a server, receive data no problem and then when I want
>>to send 1 char at a time data "key strokes" it takes a long time
>>to get the confirmation back.  Should I be using some kind of send
>>completition routine? or should I be using some kind of queing system
>>I send the data (pbcontrolasync) and then monitor the .ioresult field
>>for any errors when it returns without an error I continue.  If I
>>tried sending additional data before the .ioresult came back noerr it
>>would crash.
>>
>>what is the easiest way to send data via tcp "async"?  The way im
>>doing it doesnt seem to be async.

>The problem is that MacTCP buffers send requsts, until it's either got
>a certain amount or a certain time has elapsed.

>    It's not supposed to do that.  TCP delays ACKs, but not sends
>when the link is idle.  I know; I invented the standard algorithm
>that controls this.  Are synchronous TCP sends waiting for the
>ACK to come back, or what?  Most TCP implementations return as soon
>as the data has been queued for sending, unless the window is full
>because you've been sending large amounts of data.

John,

I tried everything I could think of, the TCP Send does return, but if you try to
send again before it gets an "ECHO" or ACK it will crash.  That is why you have to
wait until the .ioResult returns with 0 before you can send again.  That is the
problem I am having, I am unable to send keystrokes down the line, so what I did was
just buffer the data locally and when it has a few (3 chars) it sends it.

I think the only way I could see using the async send would be to monitor an abort
(ie: command-period) other than that its useless.

Do you have any other ideas?  thanks!

-Edan

+++++++++++++++++++++++++++

>From [e-mail] (Francois Pottier)
Date: 13 Nov 1996 10:06:26 GMT
Organization: INRIA Rocquencourt, BP 105, 78153 Le Chesnay Cedex, France

In article <[e-mail]>,  <[e-mail]> wrote:

> I tried everything I could think of, the TCP Send does return, but if
> you try to send again before it gets an "ECHO" or ACK it will crash.

Of course you can send again, but with a different parameter block...
That might be your problem.

--
Francois Pottier
[e-mail]
http://pauillac.inria.fr/~fpottier/

+++++++++++++++++++++++++++

>From [e-mail] (John Nagle)
Date: Wed, 13 Nov 1996 19:24:21 GMT
Organization: NETCOM On-line Communication Services (408 261-4700 guest)

[e-mail] (Francois Pottier) writes:
>In article <[e-mail]>,  <[e-mail]> wrote:
>> I tried everything I could think of, the TCP Send does return, but if
>> you try to send again before it gets an "ECHO" or ACK it will crash.
>Of course you can send again, but with a different parameter block...
>That might be your problem.

     Right.  That's what I told him in mail.

     The MacOS has really low-level I/O; it's actually chaining those
packets of yours into the OS I/O queues, so if you change them
while I/O is in progress, the I/O system will break.

                        John Nagle

---------------------------

>From [e-mail] (Peter W. Gillgasch)
Subject: [Q] Editor for *huge* text files
Date: Sat, 2 Nov 1996 19:39:48 +0200
Organization: Organised ? Who ? Me ?

Hi folks

I shortly ran into a serious problem, which may sound a bit weird
but it is real... I need to edit (or at least look at and being
able to search) text files with sizes of about 500 MB, maybe
even bigger, say up to 4 GB. Available ram on my machine is 40 mb...

Any takers ?

-- Peter

+++++++++++++++++++++++++++

>From [e-mail] (Steve Kiene)
Date: Sun, 03 Nov 1996 11:06:25 -0500
Organization: MindVision Software

In article <[e-mail]>,
[e-mail] (Paul Myers) wrote:

> In article <55h3ut$[e-mail]>, [e-mail] (Jump Long)
> wrote:
>
> > Peter W. Gillgasch wrote:
> > >I shortly ran into a serious problem, which may sound a bit
> > >weird but it is real... I need to edit (or at least look at and
> > >being able to search) text files with sizes of about 500 MB,
> > >maybe even bigger, say up to 4 GB. Available ram on my machine
> > >is 40 mb...
> >
> > MPW's editor is disk based (not RAM based), so it should be able to handle
> > files up to the Macintosh's limit. In case you're wondering, the largest
> > file you can access on a Macintosh is 2Gb.
> >
>
> No, I think it's up to 4GB with system 7.5, or way up there in the
> terabyte range if you have a PCI mac with sys 7.5/

You are thinking of the maximum volume size, not maximum file size. The
maximum file size is 2GB. Jim knows.

Steve Kiene
MindVision Software

+++++++++++++++++++++++++++

>From [e-mail] (Kirk Pennywitt)
Date: Mon, 04 Nov 1996 01:08:33 -0500
Organization: MindSpring Enterprises

In article <[e-mail]>, [e-mail]
(Anton Rang) wrote:

>  Actually, the maximum *volume* size has increased, but the maximum
>*file* size has not.  (The current File Manager APIs use a signed 32-bit
>number for both file size and offset, and there may be internal HFS
>limitations too.)


Hmm, I didn't know that.  Thanks for the clarification.  I hope someone
tells Microsoft, before they release Word 7 for the Mac :).

--kirk

+++++++++++++++++++++++++++

>From [e-mail] (Paul Myers)
Date: Sun, 03 Nov 1996 09:45:19 -0500
Organization: Net Access - Philadelphia's Original ISP

In article <55h3ut$[e-mail]>, [e-mail] (Jump Long)
wrote:

> Peter W. Gillgasch wrote:
> >I shortly ran into a serious problem, which may sound a bit
> >weird but it is real... I need to edit (or at least look at and
> >being able to search) text files with sizes of about 500 MB,
> >maybe even bigger, say up to 4 GB. Available ram on my machine
> >is 40 mb...
>
> MPW's editor is disk based (not RAM based), so it should be able to handle
> files up to the Macintosh's limit. In case you're wondering, the largest
> file you can access on a Macintosh is 2Gb.
>

No, I think it's up to 4GB with system 7.5, or way up there in the
terabyte range if you have a PCI mac with sys 7.5/

--
Paul Myers                               Department of Biology
[e-mail]                         Temple University
http://fishnet.bio.temple.edu/           Philadelphia, PA 19122

+++++++++++++++++++++++++++

>From [e-mail] (Anton Rang)
Date: Sun, 03 Nov 1996 22:59:20 -0600
Organization: Spacestar Communications, Minneapolis, MN, USA

In article <[e-mail]>,
[e-mail] (Paul Myers) wrote:
> In article <55h3ut$[e-mail]>, [e-mail] (Jump Long)
> wrote:
> > MPW's editor is disk based (not RAM based), so it should be able to handle
> > files up to the Macintosh's limit. In case you're wondering, the largest
> > file you can access on a Macintosh is 2Gb.
>
> No, I think it's up to 4GB with system 7.5, or way up there in the
> terabyte range if you have a PCI mac with sys 7.5/

  Actually, the maximum *volume* size has increased, but the maximum
*file* size has not.  (The current File Manager APIs use a signed 32-bit
number for both file size and offset, and there may be internal HFS
limitations too.)

  -- Anton

+++++++++++++++++++++++++++

>From [e-mail] (Christopher L Tate)
Date: Wed, 13 Nov 1996 17:29:05 GMT
Organization: The World Public Access UNIX, Brookline, MA

Kirk Pennywitt ([e-mail]) wrote:
: In article <[e-mail]>, [e-mail]
: (Anton Rang) wrote:
: >
: >  Actually, the maximum *volume* size has increased, but the maximum
: >*file* size has not.  (The current File Manager APIs use a signed 32-bit
: >number for both file size and offset, and there may be internal HFS
: >limitations too.)
:
: Hmm, I didn't know that.  Thanks for the clarification.  I hope someone
: tells Microsoft, before they release Word 7 for the Mac :).

Heh.  Word breaks down into little sobbing fits on *much* smaller
documents than 2GB.  In fact, getting Word to deal well with 100K
docs can be an amusing endeavour... if you're watching someone else
try it....

--
Christopher Tate (Avara: Magaera)    <*>    [e-mail]
http://world.std.com/~ctate/         <*>    Finger for PGP public key
  "0" and "1" - what could possibly be so difficult about that?

---------------------------

>From [e-mail] (Mark C Mieczkowski)
Subject: copybits problem
Date: 12 Nov 1996 21:41:45 GMT
Organization: UB

Hi,
I'm having a strange problem with copybits. I'll cut to the chase. Am I doing
this right?

...
CopyBits( &(((GrafPtr)offscreenGWorld)->portBits),
          &(((GrafPtr)projectionWindow)->portBits),
          &(offscreenGWorld->portRect),
          &(projectionWindow->portRect),
          srcCopy, NIL );
TIA,

-Mark



+++++++++++++++++++++++++++

>From Jon Karlsson <[e-mail]>
Date: Thu, 14 Nov 1996 12:06:42 +0100
Organization: CompuServe Incorporated

If you're using color, you may need to do this:

CopyBits( (BitMap*)&(((CGrafPtr)offscreenGWorld)->portPixMap),
          (BitMap*)&(((GrafPtr)projectionWindow)->portPixMap),

                                    etc.

Jon

+++++++++++++++++++++++++++

>From [e-mail] (Mark C Mieczkowski)
Date: 13 Nov 1996 20:04:28 GMT
Organization: UB

In article <56cnru$[e-mail]>,
Mark C Mieczkowski <[e-mail]> wrote:

>The specific problem is that after the call, my window gets messed up.
>The window is a noGrowDocProc. After the call to CopyBits, title bar is
>multicolored (But not in a good way :), the Title is gone, and the window
>borders are gone as well. It seems that I am copying the image over the entire
>window, including the title bar and borders. I say it seems that way because
>there is no image on the title bar, it's just a hideous color.

Okay, I'm miffed! I made no changes to the code, just restarted the computer
and now everything is working.

regards and thanks anyway. :)

-Mark



---------------------------

End of C.S.M.P. Digest
**********************